Even if we don't want learners at this stage to worry about surrogate pairs, I think we should still encourage them to use the more appropriate Array.from(string) method instead of string.split("") when converting a string into an array of characters.

My 2c would be that since none of the tests involve surrogate pairs or grapheme clusters, split('') is sufficient as a provided solution.

Array.from() is also not a bulletproof solution because while it handles surrogate pairs, it doesn't handle grapheme clusters.

// Neither of these log ["👨‍👦"] - you'd need a custom splitter
console.log("👨‍👦".split(''), Array.from("👨‍👦"));

So if the solution was to dive into or just surface-accommodate surrogate pairs, the same argument can be made for "why not also grapheme clusters?" and that's definitely way out of scope of the intent of this exercise.

The surrogate pair problem isn't something I would expect learners to reasonably face anytime soon anyway, and if they ever do, I'm confident it'd be something they'd be able to figure out from research, experiments and external help.

That's a good point about grapheme clusters, and I completely agree with you, @MaoShizhong. Array.from() is not a silver bullet for all Unicode situations, and that diving into grapheme clusters is definitely beyond the scope of this exercise.

My thinking for this change now isn't so much about making the solution perfectly robust for every Unicode edge case, but more about establishing a modern best practice from the start.

While string.split('') works for the specific tests here, it's a pre-ES6 pattern with a common failure case (surrogate pairs). My concern is that by providing it in an official solution, we're implicitly endorsing a method that students will have to unlearn later when their code breaks on a simple emoji.

Array.from(string) is the modern, built-in language standard. Using it is a simple switch that correctly handles a significantly larger and more common set of characters. It requires no extra libraries or complex understanding.

By using Array.from(string), we're not aiming for perfect Unicode compliance, but rather teaching the current, idiomatic JavaScript way to convert a string to an array. It costs nothing in terms of code complexity (in fact, [...string] is even more concise) and provides a "free" upgrade in robustness that will serve learners well.

Ultimately, I feel it's better to equip learners with the modern, more reliable tool from the beginning, even if they don't face its specific benefits within this single exercise.